Computer application programs, such as computer games, frequently include sophisticated audio that is transmitted to the user along with accompanying video. As anyone who has ever played a computer game realizes, these sound effects can range from beeps, bells, and whistles to elaborate sound patterns and sophisticated audio sequences.
The most effective audio effects are those that are perfectly synchronized with the corresponding video effect associated with the audio. For example, if the user of a computer game commands the application program to shoot a gun, the sound of the gunshot should be synchronized with the video display of the gunshot. Because the sequence of video and corresponding audio effects of computer games is necessarily unpredictable, due to user input, the problem of transmitting a particular piece of audio when other audio is being transmitted may pose a synchronization problem with certain computer systems.
Microprocessors in computer systems operate in multiple modes. Real mode is the default operating mode in certain computers based on the Intel 80.times.86 family of microprocessors and is the only operating mode supported by MS-DOS. Real mode refers to the microprocessor and the way it handles memory, but it can be characterized as providing the user with a single-tasking working environment in which programs can freely access system memory and input/output devices. Unlike the more versatile protected mode, real mode does not offer features for memory management and memory protection. When started in protected mode, these microprocessors provide hardware support for multitasking, data security, and virtual memory. Protected mode is an operating mode of certain microprocessors that supports larger address spaces and more advanced features than real mode.
Many computer systems and audio hardware devices support direct memory access (DMA). DMA involves the transfer of data without involving the microprocessor of a computer system. DMA is frequently employed for data transfer directly between the memory of a computer system and a peripheral device. However, not all peripheral devices support DMA.
DMA allows a peripheral device to directly access predetermined memory locations to retrieve or write data as necessary without participation by the CPU, with the exception of the CPU enabling interrupts, adjusting priorities, providing the address in the memory buffer where the data is located, and providing the number of bytes to be transferred. Thus, DMA allows a computer system to transfer information directly between the memory of the computer and an input/output (I/O) channel rather than taking the longer and more circuitous route from the memory to the microprocessor and then to the I/O channel.
The DMA controller controls the transfer of data through the bus from the memory to the audio hardware. The DMA controller also arbitrates access to the bus to transfer data to the audio hardware device that acknowledges signals on the DMA channel. The DMA controller transfers data through requests and acknowledgments on the bus. "System DMA" refers to computer systems in which the embedded DMA controller can control access to the audio hardware device.
Application programs designed to run on systems that support DMA are also designed to program the DMA controller to transfer data at specific locations in the RAM buffer in the computer system memory. Therefore, application programs for use in such computer systems expect the audio hardware devices connected to the system to support DMA and consequently expect DMA controller operations to exist.
Some audio hardware devices to which audio data is transferred support DMA transfers. However, some devices, such as PCMCIA-type and PCI-type audio devices, do not support system DMA because the DMA controller is not connected to the PCMCIA slot or the PCI slot in which the cards are positioned.
PCMCIA (acronym for Personal Computer Memory Card International Association) is a common standard for peripheral cards and the slot designed to hold them. PCMCIA cards typically are add-in cards that fit within predetermined slots to increase the amount of memory in a system. However, PCMCIA devices may also be dedicated cards for performing a specified function, such as a sound card.
PCI (acronym for Peripheral Component Interconnect) type audio devices are designed for operation in connection with a PCI local bus system. PCI is a specification that defines a local bus system for a computer built to the PCI specification.
Many application programs are written such that data is transferred to an audio hardware device using DMA because the application programs assume that the computer system is designed in accordance with ISA architecture. For audio peripherals based on PCI or PCMCIA standards, system DMA is not supported for the transfer of audio from the application program.
The DMA controller operates in one of two modes. One mode, called the "single cycle" mode, allows the application to program the DMA controller to transfer a specific number of bytes. When the DMA transfer reaches terminal count, i.e., the specified number of bytes have been transferred, the DMA transfer terminates. For subsequent data transfers, the application program must reprogram the DMA controller to transfer the new, predetermined number of bytes, of data.
Thus, in single cycle mode, the application commands the DMA controller to make a single transfer of a specified number of bytes of data beginning at a specified location in the buffer.
In "auto-init" mode, the DMA controller does not have to be reprogrammed to transfer data once the predetermined number of bytes have been transferred from the buffer. In auto-init mode, the DMA controller transfers data beginning at a specified memory location in the buffer. When the data has been transferred, subsequent bytes of data are automatically transferred beginning at the same memory location in the memory. Thus, in auto-init mode, the transfer of data from the buffer is effectively a circular buffer, with data filling the buffer, being transferred, and subsequent data filling the same locations in the buffer for transfer. The transfer of data in this manner continues until the application program commands the DMA controller to terminate the transfer of data.
A current implementation of an auto-init mode DMA transfer is shown in FIG. 1. The computer system, generally shown at 10, includes a CPU 12, a memory 14 including an application program 16 and a device driver 18, a bus 20, a DMA controller 28, and a peripheral device 22. In accordance with the preferred embodiment of the present invention, the peripheral device 22 is a sound card. Peripheral devices that support DMA transfers include a clock 24 and DMA logic 26. As shown in FIG. 1, the sound card is connected to a speaker 30 for transmitting sounds in accordance with the data stored in memory.
A predetermined portion of memory includes buffer 15, which is allocated for DMA transfers. Buffer 15 is a linear buffer and can also be called the DMA memory area. In FIG. 2, the data stored in the DMA memory area is shown as ranging from Byte 1 to Byte N. In accordance with the preferred embodiment of the present invention, it should be understood by those skilled in the art that each byte consists of digitized audio data.
A write pointer W and a read pointer R are associated with the buffer 15. The write pointer W determines where the application program writes data into the buffer. The read pointer R determines where the sound card reads data directly from the buffer during a DMA transfer. The write pointer W and read pointer R are separated by a predetermined number of bytes M. This separation is required such that data is not read out of the buffer from a certain location in the buffer prior to data being written into that location. Thus, the read pointer R can be thought of as "chasing" the write pointer W, yet read pointer R is always offset from write pointer W by at least M bytes. The device driver 18 maintains the positions of the pointers such that the application program knows what memory address within the buffer at which to write data and the sound card knows what memory address within the buffer at which to read data.
When the application program has written Byte N into the buffer, the application program then begins writing data again at Byte 1 and the write pointer W is reset to point to Byte 1. In this manner, the DMA memory area is analogous to a circular buffer.
In auto-init mode, a predetermined number of bytes of data are transferred from the buffer to the sound card. Thus, beginning at a memory address identified by the read pointer R, a predetermined number of bytes are transferred to the sound card. A transfer counter is updated by the DMA controller for each data transaction and when the transfer of the predetermined number of bytes is complete, an interrupt is generated by the sound card.
Assume data has been written into a memory location in the buffer, e.g., at Byte G, but has not yet been read. If the application program determines that additional data should be written into the location filled by Byte G, the application program can obtain the position of the pointers. The position of the read pointer R is important to the application program because it allows the application program to determine what data is currently being transferred to the sound card. When the application program wants to write a new sound into the buffer, e.g., to insert a gunshot sound in response to a user's input during a computer game, the application program determines where to insert the new sound by determining the position of the read pointer. The application program knows at what time the new sound should be inserted and therefore, the application moves an appropriate number of bytes forward in the DMA buffer from the read pointer R to insert the new sound. In FIG. 2, the new sound is added at Byte G. The new sound is written to the memory address of Byte G where the new sound is digitally added to the data already present in the memory location. In this manner, by obtaining the position of read pointer R, the application program can add new data to the buffer.
For peripherals that do not support DMA transfers, current operating systems provide a method simulating a DMA transfer. However, current systems only simulate a single cycle mode DMA transfer. In a single cycle DMA transfer, the application program writes data into the buffer and then the entire contents of the buffer is transferred to the sound card. In FIG. 2, Bytes 1-N are transferred in one operation from the DMA buffer to the sound card.
At an application program-determined interval (e.g., a counter set to a specific number of samples transferred to the sound card), the sound card generates an interrupt request. The interrupt is a notification that the interval has been reached and the sound card is ready for new data.
Thus, it should be appreciated that when a new sound is to be inserted into the buffer, the application program waits for the contents of the buffer to be transferred before a new sound is added. This waiting requires a time delay that may cause the new sound to be added to the buffer at a later time such that the new sound is not synchronized with a corresponding video display of the action that creates the new sound.
Current operating systems include virtual device drivers that simulate DMA transfers for hardware that does not support system DMA by using single cycle transfers. Single cycle transfers are those transfers in which the application program configures the buffer, and unmasks the DMA channel for a single transfer of a specified number of bytes. The virtual device driver translates this operation to a simple memory transfer from the buffer to the hardware.
MS-DOS applications do not rely on the operating system to control sound hardware. Instead, MS-DOS applications include their own set of drivers for various audio hardware platforms. Effectively, the application program communicates directly with the audio hardware to control sounds. The application assumes that the audio hardware supports a system DMA channel to transfer data from the application to the audio hardware.
By requesting auto-init mode DMA, the application program requests that the transfer of data be cycled by using the same memory location within the buffer until the application masks (or stops) the DMA transfer. The application determines the current location of the transfer by querying the DMA channel status and copies the data for the audio slightly ahead of the current transfer location.
When a system is simulating only single cycle DMA mode, an application program may request auto-init mode DMA transfers. In this case, most sound data will not be transferred because the application expects continuous cycling of the data in the buffer yet the system only supports the transfer of a specified number of bytes from the buffer.
The single cycle approach to simulating DMA transfers has drawbacks. Application programs expect data to be transferred at a steady rate. The contents of the buffer are not expected to change, i.e., no new data can replace data in the buffer until the contents of the buffer have been transferred to the audio hardware device. Therefore, if a new sound occurs after the buffer has been filled, that sound must wait until the contents of the buffer have been transferred to the audio hardware device until the new sound can be put in the buffer and transferred. Thus, the transfer of the new sound is delayed for the amount of time it takes to transfer data from the buffer to the audio hardware device. Therefore, the driver must transfer a specified block of data in the buffer and the data cannot be broken to insert new data for transfer.
Thus, an application program, when transferring data, looks for the DMA controller and assumes the DMA controller supports auto-init mode. The application expects the DMA controller to transfer data from the current device position which may include new data since the start of the transfer request, but the simulated DMA controller has already copied the buffer to transfer a discrete number of bytes from the buffer to the sound card. Therefore, when the application wants to modify the data to insert a new sound in the middle of the data in the buffer and the data has already been transferred out of the buffer, the modification is delayed or gets overwritten.
Current operating systems do not generate notification, in the form of a callback, when the application program queries the device driver to insert a new sound into the buffer. The application program queries the device driver for the memory location in the buffer at which the current transfer of data is taking place. Thus, because the operating system does not generate notification of this query, the device driver cannot report a DMA status to the application program to properly simulate the action of the actual DMA controller. Therefore, the new sound is delayed and inserted in the buffer after the current contents of the buffer have been transferred.
Thus, current device drivers are unable to configure the system to allow the application program to assume it is operating in auto-init mode.
Current software translation layers assume that the audio hardware supports a physical system DMA channel such that the default behavior of the hardware handles the physical data transfer submitted by the application. However, audio hardware devices that do not support system DMA lack this level of compatibility. Thus, there is a need for a method that allows backwards compatibility of application programs designed for systems that support auto-init DMA for use in connection with systems that do not support DMA.